home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0062-obj. Pascal again-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  2.2 KB  |  56 lines  |  [TEXT/GEOL]
  1. Item    5451507                         21-June-89        16:36
  2.  
  3. From:   D2086                           Efficient Field Svc, C Faith, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.         ROSENSTEIN1                     Rosenstein, Larry
  7.  
  8. Sub:    obj. Pascal again
  9.  
  10. Larry,
  11.  
  12. Thanks for the reply.
  13.  
  14. As far as needing to know whether a routine is called via inherited or not,
  15. here is my reasoning for what I am trying to accomplish.
  16.  
  17. I wish to have my abstract class perform as much of the actions as are
  18. necessary,  but also warn if all the methods that should have been overridden
  19. are not.  Under the scheme you suggested the abstract method is not allowed to
  20. do anything, so all utility must be included in the method of the descendant
  21. subclass.
  22.  
  23. Using TAbstract again:
  24.  
  25. I cannot have the method DoSomething do anything in TAbstract and still warn
  26. that it should be overriden.  (Maybe this is not desirable?)
  27.  
  28. Say I have an abstract class that is a database handler.  I want methods of
  29. that object that do things with the database.  Some of these things are general
  30. and will be the same for all subclasses of the database handler.  Some will
  31. need to be implemented according to the individual needs of the subclass, a
  32. different set of things for a subclass that uses InsideOut than one that used
  33. internal database management routines.
  34.  
  35. I want the abstract class's methods to be able to implement the generic things
  36. via INHERITED and yet still warn the programmer If the call is not the result
  37. of an INHERITED statement, i.e. it was not OVERRIDDEN.  The specific object
  38. TInsideOut for instance can use the inherited general items and add its own
  39. more specific ones and no warnings would be issued.  But at the same time the
  40. programmer is given warnings if he does not implement all the methods that need
  41. to be implemented to make a truly functional subclass.
  42.  
  43. Regarding method optimization,  I was under the impression that calls to
  44. routines in other segments use jump table addressing and calls to routines in
  45. the same segment use direct JSR's.  If a method called a method in another
  46. segment does the method use jump table addressing to locate the method table
  47. for that method?  Or does it do something entirely different?
  48.  
  49. hope this makes sense,
  50.  
  51. Curtis Faith
  52.  
  53.  
  54.  
  55.  
  56.